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(57) A method and system for updating device iden- 
tification and status information in response to a local 
bus reset within a home audio/video network. Several 
consumer electronics products, e.g.. television, VCR, 
tuner, set-top box (e.g. Intelligent receiver/decoder, 
IRD), DVTRs. PCs, DVD players (digital video disk), 
etc., can be coupled within the network to communicate 
together via a standard bus, such as an IEEE 1 394 serial 
communication bus (30). In one embodiment, the com- 
munication architecture used is the home audio/visual 
initiative (HAVI) format. The HAVI network offers unique 
advantages to consumer electronic vendors because 
the architecture otters for the home network many of the 
advantages of existing computer system networks. In- 
terconnected devices can share resources and provide 
open, well defined APIs that allow ease of development 
for third party developers. Devices of the network are 
informed of the current status of the network after a local 
bus reset caused when a device (e.g. 20) is inserted into 
the network or when a device is removed from the net- 
work. After a reset, a new global unique identifier (GUID) 
list (510) is generated by a driver (320) and passed to 
a high level program (250). The high level program (250) 
then compares the new GUID list (510) with its own copy 
of an older version and generates a list of devices added 
to the network after the bus reset and a list of devices 
removed from the network after the bus reset. This in- 
formation is then forwarded to all devices on the network 
that previously specified certain call back information re- 
garding cun-ent device status. 
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Description 

[0001] The present invention relates to the field of 
communication systems. More specifically, the present 
invention relates to methods, systems and apparatus for 
providing device status information within a communi- 
cation network, such as may be used in equipment for 
home audio/video electronics. 
[0002] A typical home audiovisual equipment comple- 
ment includes a number of components, e.g., a radio 
receiver, a CD player, a pair of speakers, a television, a 
VCR, a tape deck, etc. Components are connected to 
each other via sets of wires. One component is usually 
the central component of the home audiovisual system. 
This is usually the radio receiver, or the tuner/decoder. 
The control buttons and control switches are usually lo- 
cated on the front of the tuner and in many cases, some 
or all of these buttons and switches are duplicated on a 
hand held remote control unit. A user controls the home 
.equipment by manipulating the buttons and switches on 
the front of the tuner, or altematively, manipulating but- 
tons on the hand held remote control unit. 
[0003] As consumer electronic devices have become 
more capable and more complex, demand for the latest 
and most capable devices has increased. As new de- 
vices emerge and become popular, new devices are 
purchased by consumers and "plugged" into their home 
audiovisual systems. The new device is simply plugged 
intothe system alongside the pre-existing, older devices 
(e.g., cassette tape deck, CD player, and the like). The 
new device Is plugged into an open input on the back of 
the tuner, orsome other device coupled to the tuner. The 
consumer (e.g., the user) controls the new device via 
control switches on the new device itself, or via a sepa- 
rate remote control unit for the new device. 
[0004] As the number of new consumer electronics 
devices for the home audiovisual system has grown and 
as the sophistication and capabilities of these devices 
have increased, a number of problems with the conven- 
tional paradigm emerge. One such problem is incom- 
patibility between devices in the home audiovisual sys- 
tem. In addition, where one device is much newer than 
another device additional incompatibilities may exist. 
For example, a new device might incorporate hardware 
(e.g., specific inputs and outputs) which enables more 
sophisticated remote control functions. This hardware 
may be unusable with older devices within the system. 
Another problem is the lack of functional support for dif- 
fering devices within an audiovisual system. For exam- 
ple, even though a television may support advanced 
sound formats (e.g.. surround sound, stereo, etc.), if an 
older less capable tuner does not support such function- 
ality, the benefits of the advanced sound formats can be 
lost. Another problem is the proliferation of controls for 
the new and differing devices within the home audiovis- 
ual system. Each new device coupled to the audiovisual 
system often leads to another dedicated remote control 
unit for the user to keep track of andjearh to operate. 



[0005] In view of the above, it is desired to provide a 
communication architecture in which consumer elec- 
tronics devices can be integrated. In so doing, the con- 
sumer electronics devices can offer and be expanded 
s to include advanced communications and control func- 
tionality between themselves not heretofore offered. 
Within such communication architecture integrating 
consumer electronic devices ("a consumers electronics 
network"), devices can communicate with each other 
fo and control one another. Within a communications net- 
work where devices can communicate and control other 
devices, it is important that devices and associated soft- 
ware objects be aware of the current status of devices 
in the network to provide effective communication, con- 
^5 trol and reporting functions. Therefore, what is desired 
is a system that can efficiently report device status in- 
formation to other devices and software objects within 
the communication network while requiring a minimum 
of high level application effort. 
[0006] The IEEE 1 394 serial communication bus, ac- 
cording to the IEEE 1 394 standard, assigns a 6-bit phys- 
ical identifier value (phy_id) to each device connected 
to the bus. The IEEE 1394 serial communication bus 
uses this physical identifier to communicate with a de- 
vice coupled thereto. Whenever a new device is inserted 
onto the bus (or powered on), or an existing device Is 
removed from the bus (or powered down), or both, a bus 
reset is caused. The bus reset initiates certain well 
known bus recovery communications and functions in 
accordance with the IEEE 1394 standard. 
[0007] The above described bus reset initiates certain 
well known bus recovery communications and functions 
in accordance with the IEEE 1394 standard, including 
the possible renumbering of the physical identifiers of 
the devices remaining on the IEEE 1394 bus after the 
bus reset. That is to say, the physical identifiers as- 
signed to devices on the IEEE 1 394 bus are not always 
preserved (e.g., not persistent) following a bus reset. 
[0008] However, it is also desired within the consumer 
electronics network that high level applications adopt 
abstract and persistent identifiers for devices within the 
network. Since many data structures (e.g., speed map 
and topology map) and communication channels are 
maintained and implemented within the IEEE 1394 
standard using physical identifiers, a problem exists for 
high level ajsplications that use a persistent identifier for 
each device but also need to communicate with the de- 
vices of the network and/or need access to speed map 
and topology data. What is desired is a mechanism and 
method operable within a consumer electronic network 
that provides an IEEE 1394 communication framework, 
but also efficiently provides high level applications with 
a persistent identifier for devices coupled to the network. 

[0009] Accordingly, the present invention provides a 
method and system that can efficiently report device sta- 
tus information to other devices and software objects 
within the communication network while requiring a min- 
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imum of high level application effort. Further, the present 
invention provides a mechanism and method operable 
within a consumer electronic network that provides an 
IEEE 1394 communication framework, but also effi- 
ciently provides high level applications with a persistent 
identifier for devices coupled to the network. 
[0010] A method and system are described for updat- 
ing device identification information in response to a lo- 
cal bus reset within a home audio/video network. Within 
the network, several consumer electronics products, e. 
g.. television, VCR. tuner, set-top box (e.g., intelligent 
receiver/decoder, IRD), DVTRs, PCs, DVD players (dig- 
ital video disk), etc., can be coupled to communicate to- 
gether via a standard bus (e.g.. IEEE 1394 serial com- 
munication bus). This allows devices of the network to 
control one another and obtain information regarding 
one another. In one embodiment, the communication ar- 
chitecture used is the home audio/visual initiative (HAVI) 
format. The HAVI network offers unique advantages 
consumer electronic vendors because the architecture 
offers tor the home network many of the advantages of 
existing computer system networks, namely, intercon- 
nected devices can share resources and provide open, 
well defined APIs that allow ease of development for 
third party developers. HAVI offers extended interoper- 
ability. 

[0011] Devices can be removed from or inserted into 
the network while the network is otherwise operable (e. 
g., hot modifications are allowed). Therefore, it is impor- 
tant that devices be informed of the current status of oth- 
er devices on the network following a bus reset. The 
present invention provides a mechanism whereby de- 
vices of the network are informed of the current status 
of the network after a local bus reset which is caused 
when a device is inserted into the network (including 
power on) or when a device is removed from the network 
(including power down). In accordance with the present 
invention, after a reset, a new GUID list is generated by 
a driver program and passed to a high level program. 
The high level program then compares the new (or "cur- 
rent') GUID list with its own copy of the last GUID list 
version and generates a list of devices added to the net- 
work after the bus reset and a list of devices removed 
from the network after the bus reset. This information is 
then forwarded to all devices on the network that previ- 
ously specified certain call back infoi-mation regarding 
current device status. 

[0012] In one embodiment, the high level program is 
a communications media manager (CMM) that main- 
tains a copy of the available devices (nodes) in the net- 
work in the form of a GUID list. The GUID is a persistent 
64-bit device identification number that includes a ven- 
dor code and a chip series code and thereby uniquely 
identifies every device in the network. The device or pro- 
gram that has interest in knowing what devices are new 
and what devices have been removed from the network 
provides a call back handler to the CMM. When an IEEE 
1394 compatible device (or several devices) is inserted 



in or removed from the local bus, or any other topology 
change occurs, a bus reset is generated within the net- 
work. A low level driver program, a link driver, catches 
the bus reset, updates the available devices and passes 

s this information (the new GUID list) to the CMM. The 
CMM compares its version of the GUID list with the new 
GUID list and creates new information including the new 
and removed devices. This status information is passed 
through the call back handler to each interested object. 

'0 The present invention thereby provides an efficient 
mechanism for new and/or removed device notification 
and removes the burden from high level software of 
nnaintaining a list of recently added or removed devices. 
[001 3] The invention will now be described by way of 
example with reference to the accompanying drawings, 
throughout which like parts are referred to by like refer- 
ences, and in which: 

[0014] Figure 1 A illustrates a physical port connection 
topology of an exemplary device configuration of the 

20 home audio/visual initiative (HAVI) consumer electron- 
ics network in accordance with the present invention. 
[0015] Figure 1 B illustrates a local bus connection to- 
pology of the exemplary device configuration illustrated 
in Figure 1 A in accordance with the present invention. 

2S [0016] Figure 1C illustrates a communication channel 
topology with respect to once device coupled to the 
HAVI network illustrated in Figure 1 A in accordance with 
the present invention. 

[0017] Figure 2 illustrates internal circuitry of an intel- 
30 ligent receiver/decoder device of the HAVI network of 

Figure 1A (acting as a full audio/visual, FAV, node) in 

accordance with the present invention. 

[0018] Figure 3 illustrates a complement of software 

services made available by a full audioA^isual (FAV) 
55 node of the HAVI network in accordance with the 

present invention. 

[0019] Figure 4 illustrates communication pathways 
within the HAVI software architecture in accordance with 
the present invention. 

40 [0020] Figure 5A illustrates communication flowtothe 
communication media manager (CMM) of the present 
invention from various software objects. 
[0021] Figure 5B illustrates communication flow to 
various software objects from the communication media 

<s manager (CMM) of the present invention. 

[0022] Figure 6 illustrates the IEEE 1394 local bus in- 
terface (e.g., MPEG/MV Link) with CMM in the HAVI ar- 
chitecture. 

[0023] Figure 7A and Figure 78 illustrates steps per- 
so formed within the HAVI architecture to implement mes- 
sage communication between devices. 
[0024] Figure 6 illustrates communication pathways 
between an application, a device control module (DCM), 
the CMM and a link driver in accordance with the present 
55 invention. 

[0025] Figure 9A is an illustration of a physical identi- 
fier indexed topology map data structure used by the 
present invention. 
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[0026] Figure 9B and Figure 9C illustrate, respective- 
ly, one dimensional and two dimensional physical iden- 
tifier indexed speed map data structures as used by the 
present invention. 

[0027] Figure 1 0A shows a first exemplary device net- 
work configuration within the HAVI architecture. 
[0028] Figure 1 0B shows a second exemplary device 
network configuration within the HAVI architecture. 
[0029] Figure 11 A illustrates a GUID list as construct- 
ed by one embodiment of the present invention lor the 
first exemplary device network configuration of Figure 
10A. 

[0030] Figure 118 illustrates a GUID list as construct- 
ed by one embodiment of the present invention for the 
second exemplary device network configuration of Fig- 
ure 108. 

[0031] Figure 12A illustrates a general GUID update 
status list constructed by a second embodiment of the 
present invention in response to the device network con- 
figurations of Figure IDA and Figure 108. 
[0032] Figure 1 2 Bil lust rates an 'added" GUID update 
status list constructed by a second embodiment of the 
present invention in response to the device network con- 
figurations of Figure 10A and Figure 108. 
[0033] Figure 12C illustrates a "removed" GUID up- 
date status list constructed by a second embodiment of ' 
the present invention in response to the device network 
configurations of Figure 10A and Figure 108. 
[0034] Figure 13 is a flow diagram illustrating steps 
performed by the present invention for constructing a 
GUID list in response to a local bus reset. 
[0035] Figure 14 is a flow diagram illustrating steps 
performed by the present invention for constructing and 
communicating the GUID update status lists in response 
to a local bus reset. 

[0036] Figure 15A is a flow diagram illustrating the use 
of the GUID list in accordance with the present invention 
for sending a message to a device. 
[0037] Figure 158 illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the speed map to determine corn- 
munication speed information. 
[0038] Figure 15C illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the topology map to determine to- 
pology information. 

[0039] Figure 1 5D illustrates the use ot the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the speed map to determine com- 
munication speed information where the application ref- 
erences the speed map. 

[0040] Figure 15E illustrates the use of the GUID list 
to provide an index in accordance with the present in- 
vention for accessing the topology map to determine to- 
pology information where the application references the 
topology map. 

[0041] In the following detailed description of the 
present invention, a method and system lor updatingde- 



vice identification and status information in response to 
a local bus reset within a home audio/video network, nu- 
merous specific details are set forth in order to provide 
a thorough understanding of the present invention. 

5 However, it will be recognized by one skilled in the art 
that the present invention may be practiced without 
these specific details or with equivalents thereof. In oth- 
er instances, well known methods, procedures, compo- 
nents, and circuits have not been described in detail as 

10 not to unnecessarily obscure aspects of the present in- 
vention. 

NOTATION AND NOMENCLATURE 

15 [0042] Some portions of the detailed descriptions 
which foltdw are presented in terms of procedures, 
steps, logic blocks, processing, and other symbolic rep- 
resentations of operations on data bits within a compu- 
ter memory (see Figure 2). These descriptions and rep- 

20 resentations are the means used by those skilled in the 
data processing arts to most effectively convey the sub- 
stance ot their work to others skilled in the art. A proce- 
dure, computer executed step, logic block, process, 
etc., is here, and generally, conceived to be a self-con- 

25 sistent sequence of steps or instructions leading to a de- 
sired result. The steps are those requiring physical ma- 
nipulations of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 

30 ferred, combined, compared, and otherwise manipulat- 
ed in a computer system. It has proven convenient at 
times, principally for reasons of common usage, to refer 
to these signals as bits, values, elements, symbols, 
characters, terms, numbers, or the like. 

35 [0043] It should be borne in mind, however, that all of 
these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. Unless specifical- 
ly stated otherwise as apparent from the following dis- 

40 cussions, it is appreciated that throughout the present 
' invention, discussions utilizing terms such as "process- 
ing" or "computing" or "translating" or "calculating" or 
"determining" or "displaying" or "recognizing" or the like, 
refer to the action and processes of a computer system, 

45 or similar electronic computing device, that manipulates 
and transforms data represented as physical (electron- 
ic) quantities within the computer system's registers and 
memories into other data similarly represented as phys- 
ical quantities within the computer system memories or 

so registers or other such information storage, transmis- 
sion or display devices. 

HAVI ARCHITECTURE GENERALLY 

55 [0044] Embodiments of the present invention are op- 
erable within a consumer electronics network of the 
home audio/visual initiative (HAVI) architecture. As- 
pects of the HAVI architecture network (e.g., "HAVI ar- 
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chiteclure*) are discussed to provide a general frame- 
work in which embodiments of the present invention op- 
erate. 

[0045] HAVI is an architecture for inter-operating con- 
sumer electronics equipment devices adapted tor the £ 
home network. The interoperability aspects define an 
architectural model that allows devices of any vendor to 
intenvork within the home. A feature of the HAVI archi- 
tecture is the combination of a base set of generic device 
controls (a device control software module) with a meth- io 
od to extend the base control protocol as new features 
and devices are deployed. 

[0046] The HAVI architecture supports a wide range 
of devices including intelligent receiver/decoders 
(IRDs), digital video tape records (DVTRs), video cas- '5 
sette recorders (VCRs). personal computers (PCs), dig- 
ital video disk players (DVDs), etc., corhmunicating via 
a common messaging system. Figure 1 A illustrates the 
physical port-to-port connecting configuration 10a of an 
exemplary HAVI network. Several consumer electronics 
devices ("devices') 1 2-24 are shown connected togeth- 
er with bus segments 30a-30f which couple Cplug into*) 
to ports on the respective devices. In one embodiment 
of the HAVI architecture, the IEEE 1394 serial commu- 
nication bus standard is used as a local bus platform to 2S 
provide the common messaging system. The IEEE 
1 394 serial communication bus carries both commands, 
status information and well as digital audio and digital 
video signals between devices. 

[0047] Figure 1 B illustrates a logical bus configuration so 
10b of the HAVI network of Figure 1 A. As shown in Fig- 
ure 1 B, all of the devices 1 2-24 of the HAVI network can 
be viewed as logically coupled to a common IEEE 1 394 
serial communication bus 30. Within this bus configura- 
tion 1 0b. peer-to-peer device communication is support- 35 
ed. For example, as shown in Figure 1C. any device 
(having appropriate capabilities), e.g.. device 12, can 
send or receive communication packets from any other 
device in the HAVI network. In the example of Figure 
1C. the set -top-box (e.g., an IRD) can receive messages 
from or generate messages to any of the other devices 
14-24 of the exemplary HAVI network 
[0048] The interoperability model in the HAVI archi- 
tecture provides for the following: 1 ) support for existing 
devices; 2) a default control model; 2) a means to extend 
the default control model when new devices or function- 
ality is brought to market; and 4) a common means for 
device representation (e.g.. graphics user interfaces). 
To achieve the above, the HAVI architecture defines 
three types of nodes in the home network. A base AV so 
(BAV) node is defined for devices that already exist in 
the market (e.g., VCR 22 of Figure 1 A). An intermediate 
AV (lAV) node is defined for simple devices such as 
camcorders or DVTRs (e.g.. camera 14). A full AV (FAV) 
node is defined for devices of more resources, such as 55 
IRDs or smart televisions (e.g., set-top-box 12), An FAV 
node (or device) typically contains enough hardware to 
host control modules and to support application pro- 
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grams kx:ally. The lAV devices and FAV devices com- 
municate by sending messages over the home network 
using a generic message passing system described 
more fully below: When new devices join the home net- 
work, they are recognized and added to a global name 
database (registry). The registry holds information 
about their characteristics and provides a reference to 
a handler (e.g., communication point) for that device. 
Other devices and services are able to query the registry 
to locate a device and then, using the handler, can in- 
teract with the device. 

[0049] When a device is initially added to the home 
network, the system queries the device to ascertain its 
characteristics and capabilities. Once a device's char- 
acteristics are known, the architecture provides two 
methods of controlling it. The first method, level one in- 
teroperability, uses a predefined message set based on 
IEEE 1394 AV/C-CTS. All lAVand FAV nodes can use 
this command set to access and control other devices, 
however, BAV nodes, because they are deployed before 
the architecture was defined, are controlled using lega- 
cy protocols. The level one interoperability provides a 
default level of control. The FAV nodes act as control 
nodes and create a local representation of the 1 AV node, 
known as a device control module (DCM), that provides 
an API used to send control commands to the device. 
[0050] Level two interoperability within the HAVI ar- 
chitecture goes farther and supports future added func- 
tionality and new devices. To achieve this, a particular 
device can carry within its ROM an override DCM that 
is uploaded from the lAV device, to the FAV device, and 
replaces the default DCM for the particular device. This 
override DCM not only contains the basic level one com- 
mand set for the particular device but also includes ven- 
dor specific commands to control advanced features of 
the device. This model allows the device to inform an- 
other object about Its particular functionality. Since the 
override DCM may be loaded onto any vendor's FAV, 
the format of the DCM is architecture-neutral. 
[0051] To allow one device to discover the capabilities 
of another device and to determine which command set 
to use with that device, a standard device description 
structure is provided called the self describing data 
(SDD) structure. The SDD data structure is extensible. 
It can be a small number of bytes describing the device 
type, e.g., TV, or VTR, etc. Alternatively the SDD data 
structure can be a more complex structure also defining 
the override DCM and a graphical representation of the 
device. The graphical representation within the SDD da- 
ta structure allows an FAV node to present a pictorial 
representation of the devices in the home network to us- 
ers. 

[0052] By defining the graphical representation in a 
sufficiently generic manner, a device's SDD graphical 
data can be -used in any vendor's product to display (e. 
g., on a television or monitor within the network) a user 
interface for that device. This provides an enhanced lev- 
el of vendor interoperability and also allows a vendor to 
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differentiate a product while maintaining within the gen- 
era! look and feel of the display device. The SDD also 
enables a control device (the FAV node) to present a 
general control user interface for all devices in the home 
network, irrespective of the differences in type and ven- 
dor. Self describing data (SDD) is described in copend- 
ing provisional application serial number 60/054,327, 
entitled "A Method and Apparatus for Including Self-De- 
scribing Information within Devices," filed July 31 . 1997 
and assigned to the assignee of the present invention. 
The above referenced provisional patent application is 
hereby incorporated by reference. 
[0053] Legacy devices are devices that were built be- 
fore the HAVI architecture or devices that select not to 
use the HAVI architecture. The HAVI architecture sup- 
ports Legacy devices by providing Legacy DCMs to pro- 
vide protocol conversions for Legacy devices. These 
Legacy DCMs can contain sufficient knowledge to allow 
them to support an existing 1 or 2 way control protocol 
and provide a specific control interface to the devices 
that conform to the HAVI architecture. A legacy DCM 
acts as a bridge between the Legacy and HAVI devices. 
This feature allows the HAVI architecture also to interact 
with any future device control protocols such as, for ex- 
ample, protocols being used for home energy manage- 
ment or security, etc. 

SET-TOP-BOX -12 OF FIGURE 2 

[0054] Any consumer electronics device can be pro- 
vided with the appropriate hardware to act as an FAV 
and thereby provide a platform tor certain HAVI software 
(described below). For instance, the set-top-box 12 de- 
vice of the exemplary HAVI network of Figure 1A con- 
tains special hardware components that provide an op- 
eration platform for software components of the HAVI 
architecture. Another example of an FAV is a digital tel- 
evision having the required hardware resources to sup- 
port HAVI software. Certain aspects of the present in- 
vention, described below, are discussed in terms of 
steps executed on a computer system (e.g., processes 
400, 700, BOO. 850. 900a, 950a, 900b and 950b). Al- 
though a variety of different computer. systems can be 
used with the present invention, an exemplary general 
purpose computer system is shown in the set-top-box 
FAV of Figure 2. 

[0055] Set-top-box 12 of Figure 2, in addition to hav- 
ing a video/audio receiver (decoder) unit 1 06 and MPEG 
unit 107 also includes an internal address/data bus 100 
for communicating information, one or more central 
processors 101 coupled with the bus 100 for processing 
information and instructions, a volatile memory 102 (e. 
g., random access inemory RAM) coupled with the bus 
100 for storing infomnation and instructions for the cen- 
tral processor 101 and a non-volatile memory 103 (e.g.. 
read only memory ROM) coupled with the bus 100 for 
storing static infornoation and instructions for the proc- 
essor 1 01 . Set-top-box 1 2 can also optionally include a 



data storage device 104 ("disk subsystem") such as a 
magnetic or optical disk and disk drive coupled with the 
bus 1 00 for storing information and instructions. Also in- 
cluded in the set-top-box 12 is a bus interface unit 108 
s for interfacing with the local bus 30 (e.g.. an IEEE 1394 
serial bus). Set-top-box 12 can operate under a variety 
of different operating systems (e.g., Windows operating 
system, DOS operating system, Macintosh O/S), but in 
one embodiment the Aperios operating system is used. 

10 

HAVI SOFTWARE ARCHITECTURE 

[0056] In one embodiment, the software of the HAVI 
architecture can be broken into three APIs (AVOS, In- 

'5 teroperability and application). The AVOS API is a low 
level system API that abstracts the common operating 
system services, e.g., threads, communications, and 
memory. Interoperability . APIs are abstractions of com- 
mon device control models and provide a basic repre- 

^0 sentation model and a means to extend the control mod- 
el with vendor specific commands. The application API 
is a high level API for applications including interactive 
TV applications, and in one embodiment is based on the 
DAVIC API set including the Motion Hypermedia Expert 

'5 Group (MHEG) interactive appHcation engine. 

[0057] Figure 3 illustrates the software architecture 
,200 used in the HAVI architecture in more detail. The 
architecture 200 contains several generic components 
to provide abstractions of common facilities in the home 

0 network. A communication media manager 250 is pro- 
vided and this component abstracts from the underlying 
transport network. In the case of the IEEE 1394, the 
communication media manager 250 maintains and gen- 
erates information regarding the speed maps 515 (Fig- 

5 ure B) and topology maps 520 which are used by em- 
bodiments of the present invention. A DCM Manager 
270 is also provided that is responsible for identifying 
arid creating generic DCMs 230 for level one interoper- 
. ability. The DCM Manager 270 also hosts override DC- 

3 Ms uploaded from devices or other sites. A Graphics 
Management unit 220 is provided which supplies gener- 
ic graphics APIs that applications and DCMs can use to 
present user interface information. 
[0058] A Stream Manager 335 of Figure 3 is used to 

' determine the most effective route for AV streams within 
the home network. A data format manager is included 
within the Stream Manager 335 and is responsible for 
providing conversion of AV streams to and from various 
formats as they flow between devices in the home net- 

' work. These operations are described below with refer- 
ence to Figure 7A and Figure 7B. A Messaging Manager 
212 supports a generic messaging mechanism that al- 
lows devices to locate and interact with other devices in 
the home network. A communications media manager 

= (CMM) 250 is a media dependent entity in the HAVI soft- 
ware architecture 200. The CMM 250 provides abstract 
services to other HAVI components or application pro- 
grams in the HAVI network. It also provides media spe- 
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cific transport mechanisms for actual data communica- 
tion among various devices in the. home network. The 
CMM 250 is responsible for compiling new GUID status 
updates upon a local bus reset. It is appreciated that 
each physical communication media contains its own 
CMM to serve the above purposes. As one example, the 
CMM 250 .tor the IEEE 1394 serial bus is described 
herein further below. 

[0059] The Event Manager 214, the Registry 216. the 
Stream Manager 335 and the Initialization Manager 21 0 
of Figure 3 are described separately further below. 
[0060] Figure 4 illustrates a data flow diagram 305a 
with the HAVI software architecture 200 including an in- 
terface with the local bus HAL layer 330 for local bus 30. 
In diagram 305a, the top layer is an application program 
layer ('application layer") 220 which can communicate 
with a function control module (FCM) layer 314 having 
AV/C comnnand. The application layer 220 resides with- 
in a FAVand can also communicate with device control 
modules (DCMs) 230 and with the Registry 216. The 
application layer 220 communicates with a Stream Man- 
ager 335. The DCMs 230 are controlled by the DCM 
manager 270 which can communicate with the Event 
Manager 214. The Event Manager 214 communicates 
with the CMM 250. The Stream Manager 335 allows 
communication between the application layer and the 
CMM 250. The AV Messenger unit 212 also communi- 
cates with the CMM 250. The CMM 250 provides an in- 
terface with the local bus interface 330 via a link driver 
unit 320. The link driver unit 320 is responsible for com- 
piling new GUID lists upon a local bus reset. Higher level 
applications are located with block 310 and lower level 
applications within block 312. A subset of this commu- 
nication diagram 305a is illustrated in Figure 8. 
[0061] Figure 5A is a diagram 340a that illustrates 
communication channels that are available for commu- 
nicating to the CMM 250. The application layer 220 com- 
municates with the CMM 250 to obtain bus generation 
infomnation. to obtain the GUID list, to obtain the speed 
map 515 and to obtain the topology map 520. The fol- 
lowing APIs are used to perform these functions: get- 
GUI DList(); getBusGenerationQ; getSpeedMapQ; and 
getTopologyMap(). The ilink transportation adaptation 
module, TAM, 212b communicates with the CMM 250 
for asynchronous requests and asynchronous respons- 
es. The digital l/F controller 335a communicates with the 
CMM 250 for asynchronous requests, asynchronous re- 
sponses, channel allocations, channel deallocations, 
bandwidth allocations and bandwidth deal locations. 
The Stream Manager 335 utilizes GUID infornnation to 
establish point to point communications via the digital 1/ 
F controller 335a. The digital l/F controller 335a com- 
municates with the CMM 250 using the following APIs: 
allocateChannel(); deallocateChannel(); allocateBand- 
width(); and deallocate Bandwidth (). The isochronous 
data transceiver 230 is a DCM and communicates with 
the CMM 250 using the following APIs: isoOpen(); iso- 
CloseO; isoAttachO; isoDetach(); and isoControl(). 
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[0062] Figure 5B is a diagram 340b that illustrates 
communication channels that are available for commu- 
nicating from the CMM 250 to other objects. The CMM 
250 communicates bus reset indications to the Event 

5 Manager 214. The CMM 250 also communicates status 
information regarding the set of current devices on the 
local bus 30 including information as to which devices 
are added and which devices have been removed from 
the local bus 30 since the last GUID list was constructed. 

TO The CMM 250 also communicates bus reset information 
to the ilinkTAM 2l2b as well as GUID information, asyn- 
chronous receive, and isochronous receive. This same 
infornnation is also communicated from the CMM 250 to 
the isochronous data transceiver module 230. Informa- 

^5 tion regarding which devices are coupled tothe local bus 
30 is also communicated from the CMM 250 to the digital 
l/F controller 335a. 

[0063] Figure 6 illustrates an exemplary interface 360 
between the CMM 250 and the local bus 30 for IEEE 

20 1394 interfacing. A 1394 Bus Manager 370 is also 
shown. The CMM 250 contains a copy of the speed map 
51 5 and the topology map 520 (described further below) 
and and IEEE 1394 Bus Manager 370 contains control/ 
status registers (CSRs). The isochronous resource 

2S manager 372 contains information regarding the bus 
master identification and the available channels and 
bandwidth for communication via isochronous registers 
(CSRs). The node controller 374 contains a configura- 
tion ROM as well as node control registers (CSRs). 

30 Units 250. 372 and 374 constitute the serial bus man- 
agement unit 370. Unit 370 communicates with 1394 
HAL interface (i/F) layer 330. The transaction block 378 
processes read/write/lock transactions, tracks pending 
transactions and controls retry protocol operations with 

35 a busyAimeout register. Data transmission takes place 
within the link layer 380 and the l/F (CFR) unit 385. 

DCM 230 AND DCM MANAGER 270 

40 [0064] A description of the DCM 230 and the DCM 
manager 270 of F igure 3, as well as other aspects of the 
HAVI software architecture 200 are described in co- 
pending US patent application serial number 
, entitled "A Home AudioNideo Net- 

45 work with Two Level Device Control", by R. Lea and A. 
Ludtke, filqd concurrently herewith, attorney docket No. 
SONY-50L2278. assigned to the assignee of the 
present invention and hereby Incorporated herein by ref- 
erence, 

so 

THE COMMUNICATIONS MEDIA MANAGER 250 

[0065] The CMM 250 (e.g., for the IEEE 1394 bus) of 
Figure 4 provides two levels of APIs. One is the high- 
55 level API that interacts with other HAVI components to 
offer abstract services such as topology map 520 and 
speed nr^p 515 as well as generating HAVI related 
events. The other level of APIs is the low-tevel API that 
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provides a basic transport mechanism tor both asyn- 
chronous and isochronous data transfers. Normally, 
high-level APIs are available to any HAVI entity or ap- 
plications residing locally on this same node, while the 
low-level APIs presents the primary interlace to the 
IEEE 1 394 bus 30 so that specific protocols can be built 
on top of the CMM 250. To access high-level APIs, the 
HAVI message system (e.g.. AvMessenger 212) is 
used, whereas access to low-level APIs can be accom- 
plished through direct calls to the CMM 250. 
[0066J The messaging used to access high-level APIs 
through HAVI message system is done using a format 
having a multi-byte selector followed by function de- 
pendent parameters. The function selector determines 
which service to use from the CMM 250, and the param- 
eters section provides all required parameters for the 
specified function. To invoke low-level APIs, only the pa- 
rameters section is necessary. 
[0067] The IEEE local bus 30 is a dynamically config- 
urable network. After each bus reset, a device can have 
a complete different physical identifier (phy.id) than it 
had before the bus reset. If a HAVI component or an 
application has been communicating with a device in the 
HAVI network it generally desires to continue the com- 
munication after a bus reset even though the device may 
have a different physical identifier. To identity a device 
uniquely regardless of frequent bus resets, the present 
invention provides the Global Unique ID (QUID) which 
is used by the CMM 250 and other HAVI entities. A GUID 
is a multi-bit number (e.g., 64-bits in one implementa- 
tion) that is composed of 24 bits of node-vendor identi- 
fication and 40 bits of chip (series) identification. While 
a device's physical identifier may change constantly, its 
QUID is permanent within the HAVI architecture. The 
CMM 250 of the present invention makes device GUID 
information available for its clients using a GUID list dis- 
cussed further below. 

[0068] The CMM 250 abstracts the underlying devici9 
interconnection mechanism, providing a common set of 
API's to describe the capabilities of the bus architecture. 
In one embodiment, the CMM concept is driven by the 
IEEE 1 394 bus model, but is sufficiently abstract to pro- 
vide a general service for interconnection management. 
The CMM 250 provides APIs for 4 four basic concepts. 

(1) Channel: a channel is a logical data connection that 
a bus can support. For technology such as IEEE 1394, 
this maps directly to hardware support for multiple chan- 
nels. For technology that only supports a single data 
connection, then this degenerates to a single channel. 

(2) Bridge: a bridge is a connection between two bus 
technologies and allows channels to span different bus 
technologies. (3) Node: a node is a physical endpoint 
for a channel and corresponds to a unit or subunit in the 
HAV architecture. (4) Bandwidth: this is a metric of how 
much data can be carried on a bus at any one time. 
Bandwidth can be assigned to channels to support the 
required data rates for whatever data the channel is de- 
livering. 



[0069] For those bus protocols which do not support 
these concepts, the results of API calls to their CMMs 
have limited results. For example, if a particular bus 
technology does not support multiple simultaneous data 
s transfer actions, then it most likely reports only a single 
"channel." even though it does not really support chan- 
nels. The CMM 250 maps transactions to the channel 
model. 

[0070] There is one CMM 250 for each physical inter- 
w face (e.g. 1394, Control A1, TCP/IP) on a FAV node. 
Because theriB can be more than one kind of CMM 250, 
and because there can be many of them in existence, 
each CMM 250 has a module_type attribute attached to 
its entry in the Service Registry 216 database. The def- 
inition of this attribute can be as follows: 
modulejype = busManager 

module.data = (1394. Control A1 . TCP/IP. etc.) These 
bus types will have numeric identifiers defined for them. 
Each CMM 250 contains the general set of API's for bus 

20 nnanagement, as well as protocol-specific API's. If a par- 
ticular bus technology supports features that are above 
and beyond the general model, then it can subclass the 
CMM base class and add the new functionality For ex- 
ample, the 1394 CMM 250 allows access to the 

2S 1 394-specific bus attributes such as the isochronous re- 
source manager. Those clients who are 1394-aware, 
and need such capabilities, can go through the 1 394 
CMM 250. 

[0071] One of the advanced features the 1394 bus 

30 provides to the HAVI architecture is its support for dy- 
namic device actions such as hot plugging (device in- 
sertion or power up) and unplugging (device removal or 
power down). To fully support this to the user level, high 
level software clients need to be aware of these envi- 

35 ronment changes and the present invention provides 
this information. The CMM 250 works with the Event 
Manager 214 to detect and announce these dynamic 
bus changes using device status tables (Figure 12A, 
Figure 128. Figure 12C). Since any topology change 

40 within 1394bus will cause a bus resetto occur, the CMM 
250 is informed of these changes and notifies the Event 
■ Manager 21 4 of these changes along with the informa- 
tion about devices that have disappeared as well as 
those that have become available. The Event Manager 

45 214 then distributes the related event to all interested 
HAVI entities or applications that previously established 
the proper call back handlers. 
[0072] There are two basic types of events that are 
generated from the CMM 250 to support dynamic up- 

50 dating of available devices in the network. One is 
NEW_DEVICE which indicates a new device, and the 
other is GONE_DEVlCE, indicating a device has been 
removed. To increase efficiency, the CMM 250 gener- 
ates device status tables with this intomnation. Whenev- 

55 er a device is added or removed from the network, a bus 
reset is generated and CMM 250 finds and passes a 
status table of new/gone devices to the Event Manager 
21 4 if the Event Manager 21 4 has requested such serv- 
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ice. Since NEW_DEVICE or GONE.DEVICE also indi- 
cates the occurrence of a bus reset, the Event Manager 
214 may also create a BUS.RESET event based on the 
above information. It should be noted that aM these 
events are generally "local.' which means that the Event s 
r^anager 214 does not generally send/broadcast such 
events to any other nodes. 

[0073] The Cf^M 250 also provides topology, speed 
maps, and other environment descriptions to'its clients. 
The topology map 520 (Figure 9A) depicts the connec- io 
tivity among physical devices. Within the present inven- 
tion, rt can be used to build a human interlace that helps 
the user understand how devices are connected and 
how certain features may be used. The speed rnap 515 
(Figure 98, Figure 9C) provides information on the pos- 
sible maximum speed that can be used for data trans- 
mission between any two devices in the network. Speed 
maps provide information about the connectivity and 
performance of sections of the HAV network. It can be 
used to analyze the current connection scheme and give 20 
the user helpful suggestions for improving the perform- 
ance of devices by rearranging the connections. It at- 
tributes such as the topology map 520 cannot be auto- 
matically generated, then a dialog with the user may be 
required. When a topology request is made to a CMM 25 
for a protocol that does not support automatic topology 
detection, the request can trigger such a dialog. After, 
interacting with the user to determine how its devices 
are connected, the CMM returns the requested informa- 
tion. 30 
[0074] Topology map 520 and speed map 515 may 
change constantly because their organization (e.g., da- 
ta order) is based on the physical identifiers ot the de- 
vices on the network and these values can become re- 
assigned due to the allowed dynamic insertion or remov- 35 
a! of devices. To identify the right 'version" for these 
maps, a bus generation number may be used. Newer 
bus generation values signify the change ot bus config- 
uration. It may also be used to check if a pending oper- 
ation is 'stale'. Since transactions between devices re- <o 
quire the existence ot those devices, it is possible that 
a pending transaction has not yet completed and one or 
more devices involved have gone away. When this hap- 
pens, a new bus generation number will be generated 
and the related process can check against this new gen- <s 
eralion number to make proper clean up for the stale 
transaction. 

[0075] Bus generation number, topology map 520, 
and speed map 51 5 remain unchanged between bus re- 
sets. To improve efficiency, the CMM 250 nnay optionally 50 
cache them internally and keep them updated only when 
bus reset occurs. 

[0076] Another feature of the IEEE 1 394 bus 30 is its 
capability to send timing-critical stream through its iso- 
chronous channels. To send data in isochronous mode, ss 
channel number and proper bandwidth need to be allo- 
cated from the bus. The CMM 250 provides such serv- " 
ices to allocate/deallocate channel numbers and band- 



width for its clients. It is also responsible to restore these 
resources for its clients right after each bus reset so that 
any existing isochronous data transaction will not be dis- 
rupted because of the unavailability of these resources. 
[0077] The CMM 250 also provides a transport mech- 
anism to actually transfer the data, which is part of low- 
level services. There are two types of data transactions 
with IEEE 1394 bus 30. One is asynchronous, the other 
isochronous. Typical asynchronous transfer includes 
quadlet/block write, quadlet/block read, and lock oper- 
ations. Typical isochronous data transfer normally in- 
volves allocating channel/bandwidth, opening iso- 
chronous data port, attaching data butfer(s), and acti- 
vating data transfer. These services provide a funda- 
mental transport mechanism for a 1 394 based H AVI sys- 
tem being functional. 

[0078] The following APIs are provided by IEEE 1 394 
specific CMM 250 within the present invention: 

1) CMM::enrollComeNGo() 

Status: enrollComeNGo(ObjectlD old. (void *) (*) 
callback_handler) 

This command is used by the Event f^nager 214 
to get a list of new and removed devices when bus 
reset occurs. The Event Manager 214 enrolls such 
request to the CMM 250 to get the service. The pa- 
rameter old is the caller's object identifier and 
callback_handler is the callback function provided 
by the caller. The caller (typically Event Manager 
214) enrolls its OlD and a callback handler to the 
CMM 250 so that when bus reset occurs, the CMM 
250 invokes the callback function with a list of de- 
vices (device status table) that are either new or 
gone. 

2) CMM::getGUIDList() 

Status: CMM 250::getGulDList(GUID *guid) . 
This command gets the GUID for all active devices 
in the network. The parameter guid is a pointer to a 
the GUID list. 

3) CMM::getBusGeneration() 

Status: CMM::getBusGeneration(uint32 
*bus_en_number) 

This command gets the current local bus generation 
number from the network. The parameter 
bus_en_number is the current bus generation 
number. 

4) CMM: :getSpeedMap() 

Status: CMM::getspeedMap(uint32 
bus_en_n umber u_char *spd_map) 
This command gets the speed map 515 which is 
associated with the bus generation number speci- 
fied. The parameter bus_en_number is the current 
bus generation number, spd_map is a pointer to the 
speed map 515 
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5) CMM::getTopologyMap() 

Status: CMM::getJopologyMap(uint32 
bus_en_n umber. uint32 * top^map) 
This command gets the topology map 520 that is 
associated with the bus generation number speci- s 
tied. The parameter bus_en_number is the current 
bus generation number and top_nriap is a pointer to 
an array of integer numbers, each representing a 
selLlD packet trom a 1394 node. 

6) CMM::allocatechannel() 

Status: CMM:: allocateChannel(uint32 chan_no) 
This command allocates a channel specified by 
chan_no. If chan.no is all ones (Ox FFFFtfff), any 
channel available will be allocated and returned. '5 
The parameter chan_no is a channel number to be 
allocated. 

7) CMM::deallocatechannel() 

Status: CMM::dealiocateChannel{uint32 chan^no) 20 
This command deallocates a channel specified by 
chan_no. The parameter chan_no is the channel 
number to be deallocated. 

B) Cf^M::allocateBandwidth() 25 
Status: CMM:: allocateBandwidth(uint32 band- 
width) 

This command allocates the bandwidth specified by 
bandwidth. The parameter bandwidth is the band- 
width to be allocated. -^o 



GUID, remote_offset is the target device's meriKiry 
offset, data is the pointer to data to be received, 
data.size is the size of data (in byte) to readback 
from remote site, and pkjormat is the f ornoat to use. 
either quadlet or block for data transfer. 

12) CMM::asyncLock() 

Status: CMM::asynclock(GUID guid, ujnt64 
remote.offset, u_char *old_data u_char 
•new_data, uint32 data.size uint32 exLcode) 
This command makes a lock operation on the spec- 
ified address in the remote device. The parameter 
old_data is used for compare and swap operation. 
The parameter guid is the target device's GUID, 
remote_offset is the target device's memory offset, 
old_data is the pointer to old data, new_data is the 
pointer to the new data, data.size is the size of data 
(in byte) to be sent, and ext_code is the extended 
code to be used for the lock operation 

13) CMM::isoOpen() 

Status: CMM::isoOpen(uint32 direction, uint32 
bus_speed, uint32 bandwidth, uint32 *port-no) 
This command opens an isochronous port for either 
sending or receiving operation. The actual port 
opened is returned in pon_no. The parameter direc- 
tion is the sending or receiving operation. 
bus_speed is the requested bus speed, bandwidth 
is the maximum bandwidth to be used, and porLno 
"is the port number successfully opened 



9) CMM::deallocateBandwidth() 

Status: CMM::deallocateBandwidth(uint32 band-, 
width) 

This command deallocates the bandwidth specified 35 
by bandwidth. The parameter bandwidth is the 
bandwidth to be deallocated. 

10) CMM::asyncWrite() 

Status: CMM::asyncWrite(GUlD guid. u_tnt64 40 
remote_offset, u_char *data, uint32 data size, 
uint32 pkjormat) 

This command sends an asynchronous write re- 
quest to the remote device, which is identified by 
guid. The parameter guid is the target device's 
GUID, remote_offset is the target device's memory 
offset, data is a pointer to data to be sent, data_size 
is the size of data (in byte) to be sent and pkjormat 
is the format to use, either quadlet or block for data 
transfer. 

11) CMM::asyncRead() 

Status: CMM::asyncRead(GUID guid. ujnt64 
remote_offset. u_char *data. uint32 data_size. 
uint32pkJornaat) 

This command sends a asynchronous read request 
to the remote device, and returns the data read 
back. The parameter guid is the target device's 



14) CMM::isoClose() 

Status: CMM: :isoClose(uint32 port-no) 
This command closes the port specificed. The pa- 
rameter port_no is the port number to be closed 
Close the port specified. 

15) CMM::isoAttach() 

Status: CMM::iosAttach{uint32 porLno, u_char 
*buffei-) 

This command attaches a user buffer to the speci- 
fied port. The parameter porLno is the port number 
to be used and buffer is the data buffer. 

16) CMM::isoDetach() 

Status!. CMM::iosDetach(uint32 port-no, u_char 
^buffer) 

This command detaches a user buffer from the spe- 
cificed port. The parameter port_no is the port 
number to be used and buffer is the data buffer. 

17) CMM::tsoControl() 

Status: CMM::isoControl(uint32 chan, uint32 trig- 
ger) 

This command controls the actual data transfer. It 
starts immediately or on some synchronization bit. 
The parameter chan is the channel to be used for 
the transfer and trigger is the method to use to start 
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the traffic. 

[0079] In addition to the basic four abstractions dis- 
cussed above (Node, Channel. Bridge and Bandwidth), 
the following concepts describe the bus model. The to- 
pology nr^ 520 is a connected graph which mirrors the 
physical connections between nodes on the network. 
- For IEEE 1 394, the nnap is generated autonr^tically. For 
other protocols, manual assistance from the user may 
be required. The overall system topology is an amalga- 
mation of individual bus topologies. The generation 
number provides a way to measure whether a pending 
operation is 'stale." Since transactions between devices 
depend on being able to access those devices, it is pos- 
sible that a pending transaction has not yet completed 
and one or more of the devices involved have gone 
away. When this happens, any modules that care about 
the bus generation react accordingly. 
[0080] The generation value is based on the ability to 
determine that the bus configuration has changed. For 
protocols such as IEEE 1394, the generation is critical 
because of hot plugging support. For others, if hot plug- 
ging support can be simulated, then the generation 
number can be managed as well. If no hot plugging sup- 
port can be created, then the generation number will al- 
ways default to "1," meaning that the bus has not 
changed since the host system was initialized. A bus 
can allow a certain maximum number of nodes (devices) 
to be connected and individually addressable at any giv- 
en time. At any given time, the CMM 250 is informed of 
how many devices are currently attached and address- 
able (number of nodes) 

[0081] As described more fully below, the CMM 250 
provides bus reset or change notification for buses that 
support dynamic connection. After a bus reset is detect- 
ed, this module assigns new "opaque' ID values to all 
devices that have just appeared, determines v\^at de- 
vices have gone away, invokes the DOM Manager 270 
module to create new DCMs, and posts a bus_change 
notification event to the Event Manager 214, which no- 
tifies all registered clients about the reset. In accordance 
with the present invention, it also provides enough in- 
formation for the clients to determine what devices have 
disappeared and about any newly discovered devices. 
The CMM 250 works with the Event Manager 214 to de- 
tect and announce dynamic bus changes that do not 
trigger system-wide interrupts or events, thus bringing 
some of the advantages of 1 394 technology to other bus 
protocols. 

[0082] The CMM 250 provides clients with the physi- 
cal topology map 520, in a manner that does not require 
clients to have bus-specific knowledge. The topology 
map 520 can be generated automatically for those con- 
trol protocols which support it, or can be generated with 
user interaction and stored for later use for those proto- 
cols that do not support automatic generation. Because 
topologies can be quite diverse, the CMM 250 provides 
a topology iterator function similar to that of the Service 



Registry 216. This function allows clients to visit each 
node in a connect ion -specific manner, with a simple API 
to move fonward or backward through the net. The client 
can determine simply that this device is connected to 

5 that one, which is connected to that one. etc. For clients 
who simply need to know about all devices in a topology, 
with no concem for connection patterns, the GUID list is 
provided. Other API's allow the query to determine if a 
• given modulelD (the identification of a DCM which rep- 

10 resents a physical device) is represented in the topolo- 
gy, etc. 

[0083] The CMM 250 also provides logical connection 
information. This is a connection model that specifies 
data flow sources and sinks. The API allows inquiries 
IS such as "given DCM module ID X. tell caller all of the 
DCMs that are listening to it." Other variations on this 
inquiry model include the ability to ask for alt currently 
active streams of a particular data type (e.g. MPEG. 
SD), etc. 

20 

EVENT MANAGER 214 

[0084] The Event Manager 214 of Figure 4 is de- 
signed to support a one-to-many model of communica- 

2S tion. It is built above the basic messaging system 212. 
Objects register interest in events which are then deliv- 
ered to their event call back entry. For instance, objects 
interested in device status information register special 
call back handlers for this information with the Event 

30 Manager 21 4. Objects can attach event filters to the call- 
back entries that allow them to filter out events that they 
are not currently interested in. For example an object 
may register for all events from display devices, but filter 
out those display devices it is not currently using. 

35 [0085] Events are broadcasted by the messaging sys- 
tem 21 2 and delivered to all objects that have registered 
an interest in the event. To achieve this, objects register 
their interest with their local Event Manager 214. The 
messaging system delivers events to all known Event 

40 Managers 214 which are then responsible for ensuring 
. that registered objects are informed about events. Fil- 
ters can be attached to Event Managers 214 to allow 
objects to filter out the events as they arrive. This gives 
an object the flexibility to register interest in an event. 

45 but have control over how each event is used. For ex- 
ample a filler could be used to specify that event X is 
only of interest if it occurs after event Y. The Event Man- 
ager 214 tracks filters and provides an API that allows 
applications and DCMs to build sophisticated event fil- 

so tering chains. 

STREAM MANAGER 335 

[0086] The Stream Manager 335 of Figure 4 provides 
55 an API for configuring end-to-end isochronous ("stream- 
ing") connections. Connections nnay be point-to-point or 
utilize unbound sources or sinks. The responsibilities of 
the Stream Manager 335 include: configuration of con- 
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nections; requesting allocation of network resources; 
maintenance ot global connection information; and sup- 
port of high-level stream operations such as plug type 
checking, splicing and bridging. 

[0087] A Stream Manager 335 runs on each FAV s 
node. The interface is based on the IEEE 1212 unit di- 
rectory model and the lEC 6 1883-FDlS plug model 
(HAVI refers to units and subunits as devices and func- 
tional components respectively). Point-to-point connec- 
tions and broadcast connections are supported. In IEEE 
1394, a broadcast connection is one in which either the 
source or sink is not specified when the connection is 
requested. Streams do not cross transport boundaries, 
but bridge devices can be used to feed one stream into 
another. Streams originate and terminate at functional is 
components (rather than devices). For IEEE 1394 net- 
works, the Stream Manager 335 is responsible for allo- 
cating PCRs (plug control registers) and requesting bus 
bandwidth. A standard naming scheme is used for 
stream types, transport types and transmission formats, 
The stream type and transport type naming schemes 
are specified by HAVI, transmission formats are the 
FMT/FDF values used in lEC 1863 Comrhon Iso- 
chronous Packets. 

[0088] A stream type identifies a media representa- 25 
tlon, this can be a data format (for digital media) or signal 
format (for analog media), e.g. CD audio, NTSC. A 
transport type identifies a transport system, two exam- 
ples are lEC 1883 (for connections running over 1394) 
and "internal" (for connections internal to a device). A 30 
transmission format identifies the data transmission pro- 
tocol used to send a stream type over a transport type. 
For lEC 1883, the transmission format corresponds to 
the FMT and FDF fields in the Common Isochronous 
Packet (CIP) header 3$ 
[0089] A stream as used by the Stream Manager 335 
is based on the Isochronous data flow model from lEC 
1883 with three differences. The first difference is that 
streams do not restrict the number of sources and so 
can have multiple sources provided the transport sup- 
ports this form ot connectivity, for example, a UDP 
"event" stream being fed by many processes. The sec- 
ond difference is that an IEEE 1 394 data flow starts at 
a device output. plug and ends at a device input plug, 
while a stream typically starts at a functional component 45 
output plug, goes to a device output plug, then a device 
input plug, and ends at a functional component input 
plug. The final difference is that streams are typed, e.g., 
for each stream there is an associated stream type iden- 
tifying the data 50 
[0030] The following summarizes the properties of 
streams; 1 ) a stream is associated with a globally unique 
stream identifier; 2) a stream is carried over a single 
channel; 3) output functional component plugs ("plugs") 
and input plugs can join a stream (this can also be stated s$ 
as "connect to the channel"); 4) a channel can be con- 
nected to zero or more output plugs and zero or more 
input plugs; 5) an input plug can join at most one stream; 
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6) an output plug can join many streams (for example a 
functional component output plug attached to several 
device output plugs); 7) a stream can be created with 
no output plug, but no data will flow over the stream until 
an output plug has joined; and 8) the upper limit on the 
number of plugs that can be connected to a channel is 
transport type dependent. 

[0091 ] A stream can be viewed as a set of plugs. The 
following rules apply to connections within a device. 
Functional component input plugs can have only one 
connectbn (from a functional component output plug or 
a device input plug). Functional component output plugs 
can have many connections (to functional component 
input plugs and/or device output plugs). Device output 
plugs can have only one connection from a functional 
component output plug. Device input plugs can have 
many connections to functional component input plugs. 
[0092] There are three procedures for adding or re- 
moving plugs from this set: 1) point-to-point procedure 
(Connect, Disconnect); 2) broadcast-out procedure 
(StartBroadcast, StopBroadcast); and 3) broadcast-in 
procedure (Tap, Untap). Connect creates a point-to- 
point connection between two plugs (e.g., a connection 
from an output plug to the channel and a connection 
from the channel to the input plug); it adds an output 
plug and an input plug to the stream (assuming neither 
are already members). StartBroadcast creates a 
"broadcast-out" connection (e.g.. a connection from an 
output plug to the channel); it adds an output plug to the 
stream (assuming it is not already a member). Tap cre- 
ates a "broadcast-in" connection (e.g., a connection 
from the channel to an input plug), it adds an input plug 
to the stream (assuming it is not already a member). Dis- 
connect, StopBroadcast and Untap drop the connec- 
tions created by Connect, StartBroadcast, and Tap re- 
spectively They remove plugs (if not used by other con- 
nections within the stream). 

[0093] Streams allow the overlaying of connections 
as described In IEC-18B3, e.g., a plug may have many 
connections (both point-to-point and broadcast) to the 
channel used by the stream. Following the connection 
semantics of lEC-1883, the Stream Manager 335 de- 
cides when to remove a plug from a stream by examin- 
ing the plug's point-to-point connection counter and a 
broadcast flag (which indicates whether or not the plug 
participates in a broadcast connection). A plug is re- 
moved frorn a stream when the point-to-point connec- 
tion is 0 and the broadcast flag is false. The underlying 
network resources used for a stream are allocated when 
the first plug is added to the stream and released when 
the last plug is removed. In the case of a channel con- 
nected to several output plugs, the manner in which the 
resulting data flow is delivered is transport type depend- 
ent and the Stream Manager 335 does not guarantee 
that all input plugs will receive data in the same order. 
[0094] The Stream Manager 335 maintains a map of 
all stream connections within the home network. This 
map includes internal connections (those within devic- 



12 



23 



EP 0 929 170 A2 



24 



es) and externa! connections (those over transport sys- 
tenr^). The Streann Manager 335 builds the Global Con- 
nection Map upon initialization, after bus reset, and pe- 
riodically while running (in case new connections have 
been added or removed by non-HAVI applications). 5 
[0095] An AV network can take on n^any topological 
configurations, depending on how the user has nnade 
the connections between devices. For example, an 
IEEE 1 394 bus allows any topology except a loop. The 
Stream manager 335 of Figure 3 works with the CMM to 
250 to provide services to assist with routing data from 
source to destination. This can include many nodes in 
between. In the event that the source and destination 
involve different data types, or are separated by a 'data 
type barrier," It will work with a data format manager and ^5 
Service Registry 216 to handle automatic or requested 
data translation services as well. Some routing can be 
performed automatically, based on the capabilities pro- 
vided by the underlying bus architecture. For example, 
the topology o1 the IEEE 1394 bus can be precisely de- 20 
termined. and therefore automatic routing between di- 
rectly-connected 1394 devices can be achieved. How- 
ever, other connection mechanisms can require interac- 
tion with the user, either to assist the user with making 
well-known connections or to have the user indicate to 25 
the controlling software how devices are connected. 
[0096] One of the most significant attributes of the 
IEEE 1394 technology is isochronous data flow. Addi- 
tional services provided by the Stream manager 335 for 
this kind of data include buffer allocation and manage- 30 
ment. Buffer management includes the provision of a 
consistent notification mechanism to let the client know 
when data is available, so that it can be processed. 
While isochronous data is flowing into a client, various 
memory buffers will be filled with that data. As each buff- 35 
er is filled, the client may want to know so that it can 
handle the data acquisition process from that point for- 
ward. 

[0097] In addition, buffer management can be simpli- 
fied for clients by having the appropriate service mod- 40 
ules partition memory in a manner that is optimized for 
the data being captured. For example, the client can al- 
locate one large space of memory, then specify that it 
will be used for capturing a stream of video data. It is 
possible that the optimum configuration of this memory <s 
is to separate it into scan line- or frame-sized segments, 
so the client can receive one complete tine or frame of 
video on each notification. Raw audio and MIDI data will 
likely have different optimum segment sizes. Such serv- 
ices require close cooperation between the Route and 50 
Data Fornoat Managers, and various service modules. 
[0098] Refer to Figure 7A and Figure 7B where an ex- 
ample process 400 is shown for setting up a data flow. 
A client wants to establish a connection between two ' 
devices, so at step 410 it calls to establish an extennal 5S 
connection of one of the two DCMs that represent those 
devices. It passes the modulelD of the other device's 
DCM as a parameter. At step 415, the DCM that was 



called then calls the Stream Manager (SM) 335 to assist 
with nnaking the connection. It passes both the source 
and destination DCM module IDs as parameters. At step 
420, the SM 335 analyzes the source and destination 
IDs, finds that they are in different nodes (this step may 
be carried out by some other entity before invoking the 
DFM). At step 425. the SM 335 asks the CMM 250 of 
the source node for the topology map 520 for its net- 
work. At step 430. the SM 335 analyzes the topology 
map 520 to find the destination node. 
[0099] At step 435 of Figure 7 A, if the destination node 
is on the topology maii^O, then no transport protocol 
translation is necessary and step 445 is entered directly 
If the destination node is not on the map, then at step 
475 (Figure 7B) the SM 335 asks the Registry 216 for 
the module with the destinationID, to look at the 
nransmission_protocor attribute, oraltenoatively, it gets 
the bus manager ID for that module/node^ At step 480. 
the SM 335 then finds a transmission protocol service 
module, and sets up the conversion process (see sep- 
arate example for these details). At step 485, the above 
process is repeated if multiple transports need to be 
bridged. 

[01 00] At step 445 of Figure 7A. the SM 335 analyzes 
the connection paths to find the best route. If no deter- 
ministically optimal path can be determined, then a best 
guess is accepted. This is done for the entire path from 
source to destination, including intermediate or cross- 
network boundaries. All necessary connections are 
made (in the case of dynamic buses such as 1 394). At 
step 450, the SM 335 analyzes the input data formats 
for source and destination.. At step 455, it the formats 
are the same, then no format conversion is necessary. 
At this point (465) the data flow route 400 is complete. 
[0101] If conversion is necessary, then at step 460, 
the SM 335 asks the Registry 216 for the appropriate 
format converter based on input and output format and 
sets up the conversion process. Note that several con- 
verters can be chained together to achieve the final re- 
sult from original source to desired destination formats. 
The data flow route 400 is then complete. 

SERVICE REGISTRY 216 

[0102] The Service Registry 216 of Figure 4 provides 
a mechanism to locate devices and services that are 
available in the HAV network. Since all devices and 
services are represented by objects, the Service Reg- 
istry 216 allows any object to advertise itself. Typically, 
resident on an FAV, the Service Registry 16 contains in- 
formation on local service objects, remote service ob- 
jects and local and remote devices. The Service Regis- 
try 216 operates by providing an API that allows objects 
to register their unique identifier, a name, and a set of 
attributes that define their characteristics including con- 
nection point information. Any object wishing to kx:ate 
a particular service or device object can do so by que- 
rying the Service Registry "21 6 for the appropriate'DCM. 
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[0103] Attributes associated with an object may be 
static or dynamic, and can be subsequently changed if 
desired. Attribute querying is carried out by specifying 
a set o1 required attributes which then returns a list of 
objects that match the required attributes. Identifiers re- 
turned as a result of a query are not guaranteed to be 
valid. This can happen in one of two ways. First, if a 
device has posted its availability into the registry and 
then has gone off-line. If the query arrives between the 
time of going off-line and actually withdrawing the sen^- 
icD from the registry, then the identifier will be stale. Sec- 
ond, if a query returns a set of identifiers, the results may 
be held within an object for an extended period of time. 
When they are finally used, it may be that the service 
has been withdrawn from the registry. 
[0104] The Service Registry 216 is a distributed serv- 
ice. Any object that registers with its local Service Reg- 
istry will be accessible via any other instances of the 
Service Registry 216 in the HAV network. Each Service 
Registry 216 works with others to ensure that entries 
are replicated or available when required. However, for 
both performance and resource reasons, it is often the 
case that an item registered in one registry will not be 
visible in another, although the system will try to ensure 
this. This implies that a simple query to a local Service 
Registry 216 nnay return the local registry's view of the 
global state. It will always be possible to cause a remote 
query to be carried out on behalf of the query to ensure 
that the global state of the system is queried explicitly 
[0105] Queries to the Service Registry 216 return ob- 
ject identifiers usable as end point for message commu- 
nication. These identifiers may refer to DCMs, services, 
or any other entity in the system accessible via the mes- 
saging system. The format of the queries allows both 
sophisticated queries that iterate over the global registry 
or simple queries that are confined to a local registry. 

MESSAGING 212 

[0106] The messaging system 212 of Figure 3 is de- 
signed to provide a reliable high level messaging service 
that supports the transport of 4 different types of mes- 
sages. (1) Commands: these flow between objects-in 
the system and are used to access functionality. When 
the target object is a device then these messages are 
sent by a DCM and contain actual device control mes- 
sages. (2) Events: events are used as a general purpose 
asynchronous communication mechanism that allows 
both devices and sen/ice modules to communicate in- 
formation. Although the messaging system 212 is used 
to carry these events they are under the control of the 
Event Manager 214 which uses a broadcast feature of 
the communications infrastructure to send events to 
those who are interested. (3) Errors: errors are similar 
to events except errors are delivered to the source of 
the command that caused the error and then broadcast. 
(4) Status: these messages are designed to be used in 
response to a query. 



[01 07] The message system 2 1 2 provides both a syn- 
chronous and an asynchronous send allowing sen/ices 
to operate in either mode. The messaging system 212 
defines a minimum capability to allow interoperability at 
5 the message level. This includes the format of identifi- 
ers, the format of message identifiers and the format of 
messages. 

[0108] The following illustrates an exemplary imple- 
mentation. Local identifiers are 56 bit and are guaran- 
10 teed to be unique to a particular host. Network identifiers 
are 128 bits and consists of a 64 bit node identifier, an 
B bit node type and the 56 bit local identifier. The generic 
format for remote messages is a 4 octet type field fol- 
lowed by a parameter block. This is referred to as the 
IS message pay load. The mechanism to support local 
messaging is implementation dependent and what is re- 
quired is that local identifiers guarantee consistent de- 
livery of the message pay load. Remote messaging 
takes a message payload and encapsulates it in a net- 
20 work message. The network message format is header 
plus message payload. The network message header 
is 96 bits and consists of a reserved 6 bit field, a 2 bit 
packet type, a 56 bit local identifier and a 32 bit message 
identifier. Depending on the actual transport mecha- 
25 nism, this remote message packet will be encapsulated 
in a transport specific message, e.g. IP or IEEE 1394. 

INITIALIZATION MANAGER 210 

[0109] The Initialization Manager 210 of Figure 3 is 
used to bring an lAV or FAV node up to initial status. In 
the case of an lAV node this manager 210 will initialize 
the messaging 212, event 21 4 and registry 216 service. 
For the FAV node it will also invoke initialization routines 
for the DCM manager 270 and any pre-loaded services. 

APPLICATION INTERFACE 220 

[0110] The Application Interface 220 of Figure 4 is a 
proxy to the messaging system 212 and provides a 
means for applications to access services and devices 
in the AV architecture. The Application Interface 220 is 
not necessarily a component of the AV architecture, but 
rather a means of allowing an arbitrary application to 
45 work with the AV architecture. The mechanism used to 
provide the^application object depends on the location 
of the application and the execution environment it uses. 
Applications can be downloaded from external services 
provided and made resident (e.g., instantiated) within 
so an intelligent device (FAV) of a HAVi network. An Appli- 
cation so downloaded can query the Service Registry 
216 to determine connection points for controlling de- 
vices of the HAVI network. There are 3 general cases. 
The first case is local application running native on the 
ss FAV node. These types of applications are designed to 
make use of the native OS and hardv^rare features of the 
FAV node. They are created externally to the AV archi- 
tecture and use the application interface to gain access 
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to the AV architecture services. The exact means to 
achieve this are system dependent, but a library linked 
into the application is a typical approach. 
[0111] Tha second case is local application running 
above the FAV interoperability language run-time. In this 5 
case, the AV architecture uses an architecture neutral 
run time to support level 2 Interoperability. This run time 
can also be used to support arbitrary applications written 
to be hosted on the run time. Such applications are man- 
aged by the AV architecture and will typically access the 
AV services via a run time supplied calling mechanisms. 
[01 1 2] The third case is remote application. These ap- 
plications nnay be running on other devices in the home 
network such as home personal computers (PCs), 
These applicatbns need access to the AV architecture ^5 
and do so by using the basic message passing model 
of the system. This implies that these applications need 
a partial implementation of the messaging infrastructure 
resident on their host node. 

20 

GRAPHICS MANAGER 21B 

[0113] The Graphics Manager 218 of Figure 3 pro- 
vides a high level API for the management of the user 
Interlace (Ul) associated with devices. The role ot the 25 
Graphics Manager 218 is to support the User Interface 
model by providing a graphics API that is semantically 
rich. Low level graphics APIs are generally located close 
to graphic displays and are used by the high level graph- 
ics API to provide and support the Ul. 30 

DEVICE IDENTIFICATION PROCESSES 

[0114] Figure 8 illustrates a portion 305b of the HAVI 
communication architecture and illustrates an applica- 35 
tlon layer 220, a device control module 230 lor a partic- 
ular device 20. the CMM 250, the link driver layer 320, 
an electronic device 20 coupled to the IEEE 1394 com- 
munication bus 30 and the speed map 51 5 and topology 
map 520 data structures. The location of the CMM 250 40 
and the link driver layer 320 in the overall architecture 
of HAVI is shown in interface 305a of Figure 4. 
[0115] As described above, the presentjnvention al- 
lows high level software programs (e.g.. the application 
layer 220) to reference devices using a persistent iden- 45 
tification scheme. Namely, multi-bit "persistent Global 
Unique Identifier numbers (GUlDs) are assigned to 
each device and contain a vendor portion and a chip 
series portion. It one embodiment, a 64-bit number is 
used as the GUID. Figure 8 illustrates an exemplary so 
communication path whereby the application layer 220 
issues a command to cause device 20 to perlorm some 
predefined action (e.g., to start "playing' some media). 
The initial command from the application layer 220 in- 
cludes an abstract identifier (e.g.. "VCRI ") of the DCM 55 
230 object and also the action to be done (e.g., "play"). 
[01 1 6] The DCM 230 of Figure 8 converts the abstract 
object name into a GUID that matches device 20 and 
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issues another command including the GUID and the 
action, "play." to the CMM 250. The CMM 250 contains 
a GUID list 510 in accordance with the present inven- 
tion. The GUID list 510 is a listing of GUIDs in order ot 
their associated physical identifications (for each re- 
spective device). Therefore, the GUID list 510 of the 
present invention functions as an efficient physical iden- 
tification to GUID translator and a GUID to physical iden- 
tification translator. The GUID list 510 is updated by the 
link driver 320 each time a bus reset event is detected. 
[0117] The CMM 250, using the GUID list 510. con- 
verts the GUID received from the DCM 230 into the cor- 
responding physical identifier for device 20. The CMM 
250 then passes a message to the link driver layer 320 
including the action comnnand, "play," and the physical 
identifier corresponding to device 20. The link driver lay- 
er 320 interfaces with the local bus 30 using the physical 
identifier thereby communicating the action command, 
"play." to the device 20. The speed map 515 and topol- 
ogy map 520 are present for other aspects ot the present 
invention described further below. 
[0118] Figure 9A. Figure 9B and Figure 9C illustrate 
exemplary speed map 515 and topology map 520 data 
structures. The entries of the speed map 51 5 and topol- 
ogy map 520 data structures are organized (e.g., or- 
dered or indexed) based on the physical identifier of the 
devices. The mechanisms for generating the speed map 
515 and the topology map 520 data structures are well 
known within the IEEE 1394 standard. 
[0119] Figure 9A illustrates an exemplary topology 
map 520 data structure used by the present invention. 
. This data structure 520 includes a respective entry (of 
entries 522a-522n) for each of the n devices coupled to 
the local bus 30. The first field 524 of each entry corre- 
sponds to the device's physical identifier as assigned by 
the local bus layer 330. As shown in Figure 9A, the en- 
tries 522a-522n are ordered according to their physical 
identifier, e.g., physicalJDO. physicalJDI, ... , 
physicalJDn. The following fields 526, 52B, 530 for each 
entry specify port information for each physical port of 
the device. The port information indicates the physical 
connection of that port to another port. Using this port 
information, one can determine the manner in which the 
n devices of the local bus 30 are physically coupled to- 
gether in the HAVI network. Topology map 520 data 
structures 'Of the format shown in Figure 9A are well 
known in the art and are re-generated upon each local 
bus reset. 

[0120] Figure 9B illustrates an exemplary one-dimen- 
sional speed map data structure 515a used by the 
present invention. This data structure 515a includes a 
respective entry (of entries 531a-531n) for each of the 
n devices coupled to the local bus 30. The first field 532 
of each entry corresponds to the device's physical iden- 
tifier as assigned by the local bus layer 330. As shown 
in Figure 9B, the entries 531a-531 n are ordered accord- 
ing to their physical identifier, e.g., physicalJDO, 
physicaLIDI, .... physicalJDn. Field 534 indicates in- 
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tormation pertinent to the communication protocol (in- 
cluding communicate rate) available for the device. 
Speed map 51 5a data structures ot the format shown in 
Figure 9B are well known in the art and are re-generated 
upon each local bus reset. 

[0121] Figure 9C Illustrates a two dimensional speed 
map 515b data structure used by the present invention. 
Speed map 515b is a matrix where each matrix entry 
546 conveys information regarding the communication 
speed between referenced devices (e.g.. devices refer- 
enced by phy_id n and phyjd 2). The speed map 515b 
has a first index 542 and a second index 544. both being 
ordered according to their physical identifiers. Speed 
map 51 5b data structures of the format shown in Figure 
9C are well known in the art and are re-generated upon 
each local bus reset. 

[0122] Figure 10A illustrates an exemplary HAVI net- 
work 560a having five devices coupled to the local bus. 
Device 562 has a physical identifier (0) and a GUID(Y); 
device 564 has a physical identifier (1) and a GUID{2); 
device 566 has a physical identifier (2) and a GUID(I); 
device 568 has a physical identifier (3) and a GUID(J) 
and device 570 has a physical identifier (4) and a GUID 
(X). Each of the GUID values is unique and persistent. 
The physical identifier values for the devices of Figure 
10A can become reassigned after a local bus reset. 
[0123] Figure 11 A illustrates the resulting GUID list 
51 Da compiled by the present invention based on the 
exemplary HAVI network 560a of Figure 10A. The GUID 
list 51 Oa contains five entries, one for each device of the 
HAVI network. As shown, the GUID values in the GUID 
list 510a are ordered, e.g., GUID(Y); GUID(Z); GUID(l); 
GU!D(J); and GUID(X), according to the corresponding * 
physical identification values. 0, 1, 2. 3 and 4. respec- 
tively In one embodiment, GUID list 510a is compiled 
by the link driver 320 and stored in computer readable 
memory. 

[0124] Figure 10B illustrates another exemplary HAVI 
network 560b having six devices coupled to the local 
bus. Network 560b is simitar to network 550a except de- 
vice 566 is removed and devices 572 and 574 are add- 
ed. In network 560b, device 572 has a physical identifier 
(1) and a GUID(U) and device 574 has a physical iden- 
tifier (5) and a GUID(N). Some ot the physical identifier . 
values between Figure 10A and Figure 10B have been 
reassigned due to a local bus reset. The reassigned 
physical identifiers for the remaining devices are as fol- 
lows; device 562 has physical identifier (0), device 564 
has physical identifier (3), device 568 has physical iden- 
tifier (4) and device 570 has physical identifier (2). Each 
' of the GUID values is unique and persistent for all de- 
vices. 

[0125] Figure 11B illustrates the resulting GUID list 
510b compiled by the present invention based on the 
exemplary HAVI network 560b of Figure 10B. The GUID 
list 51 Ob contains six entries, one for each device of the 
HAVI network 560b. As shown, the GUID values in the 
GUID list 510b are ordered, e.g.. GUID(Y); GUID(U); 



GUtD(X); GUID(Z); GUID(J) and GUID(N), according to 
the corresponding physical identification values, 0, 1 . 2. 
3, 4 and 5, respectively. In one embodiment, the GUID 
list 510b is compiled by the link driver 320 and stored in 
5 computer readable memory. 

[0126] Figure 1 2A illustrates a GUID status table 630 
generated by the CMM 250 of the present invention 
each time a local bus reset is generated. The GUID sta- 
tus table 630 includes entries 632a-632g regarding (1) 
10 which devices remain connected to the local bus 30 
since the last GUID list 510 was compiled, e.g., after a 
local bus reset, (2) which devices have been just re- 
moved and (3) which devices have been just added 
since the last GUID list 510 was compiled. A first field 
IS 632 represents the GUID value of the device and an as- 
sociated field 634 represents the current status of that 
device. Figure 12A represents an exemplary table 630 
generated by CMM 250 as a result ot the exemplary con- 
figurations of Figure 10A and Figure 108. As shown in 
20 table 630. the devices having GUID(Y). GUID(X). GUID 
(Z). and GUID(J) remain after the local bus reset. How- 
ever, the devices having GUID(U). and GUID(N) have 
been added after the local bus reset and the device hav- 
ing GUID(I) was removed after the local bus reset. In 
25 one embodiment, the GUID table 630 is compiled by the 
CMM 250 and stored in computer readable memory. 
[0127] Figure 128 illustrates a subset status table 650 
generated by the CMM 250 which contains entries 
652a-652b indicating only which devices have been 
30 added to the local bus 30 since the last GUID list 510 
was compiled. Likewise. Figure 12C illustrates a subset 
status table 660 generated by the CMM 250 which con- 
tains entries (662a) indicating only which devices have 
been removed from the local bus 30 since the last GUID 
35 list 510 was compiled. In one embodiment, the GUID 
tables 650-660 are compiled by the CMM 250 and 
stored in computer readable memory. Device status ta- 
bles 630, 650 and 660 are forwarded to objects within 
the HAVI architecture that establish callback handlers 
40 within the CMM 250 to receive this information. 

[0128] Figure 1 3 illustrates a flow diagram 700 of the 
steps performed by the link driver 320 of the present in- 
vention for compiling a current GUID table 510 in re- 
sponse to a local bus reset. After a local bus reset, phys- 
.45 icat identifiers of devices are reassigned by the local bus 
30. At step 71 0, if a local bus reset is reported to the link 
driver 320. then step 71 5 is entered. At step 71 5, current 
GUID list is erased and the link driver 320 determines 
the number of devices, n, that are currently coupled to 
so the local bus 30. A number of well known mechanisms 
can be used to implement step 71 5. At step 720, a coun- 
ter is set to zero. At step 725. the link layer 320 issues 
a request to the device coupled to the local bus 30 and 
having the physical identifier corresponding to the coun- 
55 ter value. The request is for the GUID value of this de- 
vice. At this point, the link layer 320 is unaware which 
device this is. 

[01 29] At step 730, the link layer 320 receives the re- 
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turn GUID value from the device with the physical iden- 
tifier of the counter value and places this GUID value 
into a next entry of the current GUID list 510 (the entry 
position also corresponds to the counter value). At step 
735, the counter is incremented by one. At step 740, a 5 
check is made if the counter is equal to n (the maximum 
number of devices on the local bus). If not, then step 
725 is entered again to continue compiling the current 
GUID list. If so, then at step 745, the link layer 320 for- 
wards the CMM 250 a copy ot the current GUID list 510. io 
It is appreciated that physical identifiers are assigned by 
the local bus 30 from 0 to (n-1 ) values. After process 
700, a current GUID list 510 like those shown in Figure 
1 1 A and Figure 11 B is compiled. . 
[01 30] Figure 1 4 illustrates a flow diagram 800 of the 
steps performed by the Link layer 320 and the CMM 250 
of the present invention for compiling the device status 
tables 630, 650, 660 in response to a local bus reset. 
As discussed above, process 700 generates a current 
GUID list 510 in response to a local bus reset and pass- 
es the current list to the CMM 250. At step B20, the cur- 
rent GUID list is received and the last GUID list received 
by the CMM 250 is retained and marked as a "previous" 
GUID list. At step 825, the CMM 250 compares the en- 
tries ot the previous GUID list and the current GUID list 25 
510 and generates GUID table 650 based on the new 
GUID values that are present in the current GUID list 
510 but not in the previous GUID list. Any object within 
the HAVI architecture that previously established a call- 
back handler with the Event Manager 21 4 for the infer- 30 
mation of table 650 is sent a message including the sta- 
tus information of table 650. 

[0131] At step 830, the CMM 250 compares the en- 
tries of the previous GUID list and the current GUID list 
510 and generates GUID table 660 based on any GUID 35 
values that are no longer present in the current GUID 
list 510 but were present in the previous GUID list. Any 
object within the HAVI architecture that previously es- 
tablished a callback handler with the Event Manager 
214 for the information of table 660 is sent a message 40 
including the status information ot table 650. Optionally, 
at step 830, the information from tables 660 and 650 can 
be combined with the GUID values that are common to 
both the previous and current GUID lists thereby gener- 
ating table 630. At step 835, the CMM 250 erases the 
previous GUID list and uses only the current GUID list 
510. By perlorming process 800, the CMM 250 and the 
link layer 320 of the present invention eliminate the bur- 
den from higher level application programs of tracking 
which devices are on the local bus while providing the so 
high level application programs with device status infor- 
mation. 

[0132] Figure 15A illustrates a flow diagram 850 of 
steps performed by the present invention for translating 
GUID values into physical identifications using the GUID 55 
list 510 passed to the CMM 250. At step 855, an appli- 
cation program issues a command to control a device 
(X) and this command is received by the DCM of the de- 



vice(x). At step 860, the DCM issues a command to the 
CMM 250 including device(x)'s GUID value which is 
known to the DCM. At step 865, the CMM 250 deter- 
mines the index (e.g., entry order) of the device(x)*s 
GUID within the GUID list 510. This value is the physical 
identifier of device(x). At step 870, the CMM 250 issues 
a command to the link driver layer 320 including device 
(x)'s physical identifier and an action command. The link 
driver layer 320 then commands device(x) using the re- 
ceived physical identifier. Using process 850, high level 
applications do not need to be aware ot a device's phys- 
ical identifier but can use the constant GUID value. 
[0133] Figure 15B illustrates a flow diagram 900a of 
steps performed by the present invention for accessing 
speed map information with respect to two devices giv- 
en their GUlDs. At step 91 0, an application layer issues 
a command to determine the communication speed 
supported between device(x) and device(y). The re- 
quest includes the GUID values for device(x) and device 
(y). At step 915, the CMM 250 receives this command 
and the GUID values. The CMM 250 translates the 
GUID values into two physical identifiers based on the 
index of the GUIDs within the GUID list 51 0. At step 920. 
the CMM 250 then accesses (e.g., indexes) a two di- 
mensional speed map data structure 515b with the ob- 
tained two physical identifiers. The speed map thereby 
returns the proper speed information. At step 925, the 
CMM 250 forwards the determined speed information 
to the requesting application layer. 
[0134] Figure 15C illustrates a flow diagram 950a of 
steps performed by the present invention for accessing 
topology map information with respect to a device given 
its GUID value. At step 955. an application layer issues 
a command to determine the topology of a device(y). 
The request includes the GUID value for device(y). At 
step 960. the CMM 250 receives this command and the 
GUID value. The CMM 250 translates the GUID value 
into a physical identifier based on the index of the GUID 
within the GUID list'51 0. At step 965. the CMM 250 then 
accesses (e.g., indexes) a topology data structure 520 
with the obtained physical identifier. The topology map 
thereby returns the proper topology information for de- 
vice(y). At step. 970, the CMM 250 fonvards the deter- 
mined topology information to the requesting application 
layer. 

[0135] Figure 15D illustrates a flow diagram 900b of 
steps performed by the present invention for accessing 
speed map information with respect to two devices giv- 
en their GUIDs. The difference between process 900b 
and 900a (Figure 15A) is that the application program 
determines the speed information, not the CMM 250. At 
step 980. an application layer issues a command to de- 
termine the communication speed between device(x) 
and device(y). At step 982, the CMM 250 receives this 
command and forwards the current GUID list 51 0 as well 
as a copy of the speed map 515b (or pointers to these 
data structures) to the application program. At step 984, 
the application program translates the GUID values of 
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the two devices into two physical identifiers based on 
the index dl the GUIDs within the QUID list 510. The 
application program then accesses (e.g.. indexes) the 
two dimensional speed map data structure 51 5b with the 
obtained two physical identifiers. The speed map there- 
by returns the proper speed inlormation. 
[0136] Figure 15E illustrates a flow diagram 950b ot 
steps performed by the present invention for accessing 
topology information with respect to a device given its 
GUID. The difference between process 950b and 950a 
{Figure 1 5B) is that the application program determines 
the topology information, not the CMM 250. At step 990, 
an application layer issues a command to determine the 
topology information of device(y). At step 992. the CMM 
250 receives this command and fonwards the current 
GUID list 51 0 as well as a copy of the topology map 520 
(or a pointer to this data structure) to the application pro- 
gram. At step 994, the application program translates 
the GUID value of the device(y) into a physical identifier 
based on the index of the GUID within the GUID list 51 0. 
The application program then accesses (e.g.. indexes) 
the topology data structure 520 with the obtained phys- 
ical identifier. The topology map thereby returns the 
proper topology information. 

[0137] It is appreciated that by providing the GUID list 
510, the present invention allows high level applications 
to utilize persistent device identifiers (GUIDs) to refer- 
ences devices. Upon a bus reset, the high level devices 
are not burdened with the reassignments ot physical 
identifiers that are done at the local bus level. The GUID 
list 51 0 is particularly efficient by organizing the ordering 
ot GUIDs to conform to the physical identifiervalue. This 
reduces memory required to store the GUID list 510 and 
creates an efficient index mechanism. 
[0138] The preferred embodiments of the present in- 
vention, a method and system tor updating device iden- 
tification and status information in response to a local 
bus reset wrthin a home audio/video network, are thus 
described. While the present invention has been de- 
scribed in particular embodiments, it should be appre- 
ciated that the present invention should not be con- 
strued as limited by such embodiments, but rather con- 
strued according to the below claims. 
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1. A method ot providing device status information 
within a communication network, said method com- 
prising the steps of : . . 



a) constructing a current list of global unique 
identifiers (GUIDs) by ordering respective 
GUIDs within said current list of GUIDs accord- 
ing to their associated physical identifier values 
wherein said physical identifier values are as- 
signed by a local bus of said network and each 
GUID of said current list ot GUIDs identifies a 



£5 



unique device coupled within said network; 

b) fonwarding said current list of GUIDs to a high 
level software program; 

c) said high level software program comparing 
said current list of GUIDs with a previous list of 
GUI Ds to generate a list of newly added devic- 
es to said network and of newly removed de- 
vices from said network; 

d) fonwarding said list to a device within said 
network that previously established a call back 
handler with said high level software program 
for device status information; and 

e) repeating steps a) d) in response to each 
local bus reset. 

A method as described in Claim 1 wherein each 
GUID is a persistent multi-bit value comprising a 
vendor code portion and a chip series code portion. 

A method as described in Claim 1 wherein said net- 
work is a network of the home audio/visual initiative 
(HAVI) architecture and wherein said local bus is of 
the IEEE 1394 standard. 

A method as described in Claim 1 wherein said step 
c) further comprises the step of said high level soft- 
ware program replacing said previous list of GUIDs 
with said current list of GUIDs after said comparing. 

A method as described in Claim 1 further compris- 
ing the step of said local bus renumbering physical 
identifiers of devices ot said network that are cou- 
pled to said local bus in response to a local bus re- 
set. 

A method as described in Claim 5 wherein said step 
a) comprises the steps of: 

a1) receiving from said local bus an indication 
of the number ot devices of said local bus; 
a2) starting with physical identifier zero and in- 
crementing to a last physical identifier corre- 
sponding to said number of devices of said local 
bus. forwarding requests to said devices of said 
local bus individually requesting their GUIDs; 
a3) recording into said current list of GUIDs any 
GUIDs returned from said devices of said local 
bus, said GUIDs recorded into positions said 
current list of GUIDs based on their corre- 
sponding physical identifier values; and 
a4) storing said current list of GUIDs into a com- 
puter readable memory unit. 

A method of providing device status information 
within a communication network, said method com- 
prising the steps of: 

a) constructing a current list ot global unique 
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identifiers (GUIDs) by ordering respective 
GUIDs within said current ijst of GUIDs accord- 
ing to their associated physical identifier val- 
ues, said physical identifier values assigned by 
a local bus of said network and wherein each 5 
GUID of said current list of GUIDs identifies a 
unique device coupled within said network, said 
step a) performed by first software; 

b) said first software forwarding said current list 

of GUIDs to second software; io 

c) said second software comparing said current 
list of GUIDs with a previous list of GUtDs to 
generate a first list of newly added devices to 
said communication network and a second list 

of newly removed devices from said network; >5 

d) forwarding said first list and said second list 
to a device within said communication network 

. that prevbusly established a call back handler 
with said second software for device status in- 
formation; and 20 

e) repeating steps a) - d) in response to each 
local bus reset. 

8. A method as described in Claim 7 wherein each 
GUID is a persistent multi-bit value compnsing a 2S 
vendor code portion and a chip series code portion. 

9. A method as described in Claim 7 wherein said net- 
work is a network of the home audioA/isua) initiative 
(HAVI) architecture and wherein said local bus is of 30 
the IEEE 1394 standard. 

1 0. A method as described in Claim 7 wherein said step 
c) further comprises the step of said second soft- 
ware replacing said previous list of GUIDs with said 3S 
current list of GUIDs after said comparing. 

11. A method as described in Claim 7 further compris- 
ing the step of said local bus renumbering physical 
identifiers of devices of said network that are cou- 40 
pled to said local bus in response to a local bus re- 
set. 

12. A method as described in Claim 11 wherein said 
step a) comprises the steps of: 4S 

a1) receiving from said local bus an indication 
of the number of devices of said local bus; 
a2) starting with physical identifier zero and in- 
crementing to a last physical identifier corre- 50 
sponding to said number of devices of said local 
bus, forwarding requests to said devices of said 
local bus individually requesting their GUIDs; 
a3) recording into said current list of GUIDs any 
GUIDs returned from said devices of said local ss 
bus. said GUIDs recorded into positions said 
current list of GUIDs based on their corre- 
sponding physical identifier values; and 
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a4) storing said current list of GUIDs into a com- 
puter readable memory unit. 

13. An electronic system having a processor, a bus and 
a computer readable menK>ry unit, said system cou- 
pled to a local bus, said memory unit having instruc- 
tions stored therein that implement a method of pro- 
viding device status information, said method com- 
prising the steps of: 

a) constructing a current list of global unique 
identifiers (GUIDs) by ordering respective 
GUIDs within said current list of GUIDs accord- 
ing to their associated physical identifier values 
wherein said physical identifier values are as- 
signed by said local bus and each GUID of said 
current list of GUIDs identifies a unique device; 

b) forwarding said current list of GUIDs to a high 
level software program; 

c) said high level software program comparing 
said current list of GUIDs with a previous list of 
GUIDs to generate a list of newly added devic- 
es to said network and of newly removed de- 
vices from said network; 

d) forwarding said list to a device within said 
- network that previously established a call back 

handler with said high level software program 
for device status information; and 

e) repeating steps a) - d) in response to each 
local bus reset. 

14. An electronic system as described in Claim 13 
wherein each GUID is a persistent multi-bit value 
comprising a vendor code portion and a chip series 
code portion. 

15. An electronic system as described in Claim 13 
wherein said network is a network of the home au- 
dio/visual initiative (HAVI) architecture and wherein 
said local bus is of the IEEE 1394 standard. 

16. An electronic system as described in Claim 13 
•wherein said step c) further comprises the step of 
said high level software program replacing said pre- 
vious list of GUIDs with said current list of GUIDs 
after said comparing. 

17. An electronic system as described in Claim 14 
wherein said method further comprises the step of 
said local bus renumbering physical identifiers of 
devices of said network that are coupled to said lo- 
cal bus in response to a local bus reset. 

18. An electronic system as described in Claim 17 
wherein said step a) comprises the steps of: 

a1) receiving from said local bus an indication 
of the number of devices of said local bus; 
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a2) starling with physical identifier zero and in- 
crementing to a last physical identifier corre- 
sponding to said number of devices of said local 
bus, torwarding requests to said devices of said 
local bus individually requesting their GUIDs; 
a3) recording into said current list of GUIDs any 
GUIDs returned from said devices ot said local 
bus, said GUIDs recorded into positions said 
current list of GUIDs based on their corre- 
sponding physical identifier values; and 
a4) storing said current list of GUIDs into a com- 
puter readable memory unit. 

19. An apparatus for providing device status informa- 
tion within a communication network, said appara- 
tus comprising: 

a) means for constructing a current list of global 
unique identifiers (GUIDs) by ordering respec- 
tive GUIDs within said current list of GUIDs ac- 
cording to their associated physical identifier 
values wherein said physical identifier values 
"are assigned by a local bus of said network and 
each GUiD of said current list of GUIDs identi- 
fies a unique device coupled within said net- 
work; 

■ b) means for fonwarding said current list of 
GUIDs to a high level software program; 

c) said high level software program comparing 
said current list of GUIDs with a previous list of 
GUIDs to generate a list of newly added devic- 
es to said network and of newly removed de- 
vices from said network; 

d) said high level software program forwarding 
said list to a device within said network that pre- 
viously established a call back handler with said 
high level software program for device status 
information; and 

e) means for repeating steps a) - d) in response 
to each local bus reset. 

20. An apparatus as described in Claim 1 9 wherein said 
means for constructing comprises: 

means for receiving from said local bus an in- 
dication of the number of devices of said local 
bus; 

means for starting with physical identifier zero 
and incrementing to a last physical identifier 
corresponding to said number of devices of 
said local bus, forwarding requests to said de- 
vices of said local bus individually requesting 
their GUIDs; 

means for recording into said current list of 
GUIDs any GUIDs returned from said devices 
of said local bus, said GUIDs recorded into po- 
sitions said current list of GUIDs based on their 
corresponding physical identifier values; and 



means for storing said current list of GUIDs into 
a computer readable memory unit. 
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-ISSUE COMMAND TO DEVICE{X), DEVICE(X)'s 
QUID IS INCLUDED IN THE REQUEST 



-860 



I 



CMM USES CURRENT QUID LIST 
AND DEVICE(X)'s QUID TO 
OBTAIN PHYSICAL ID OF DEVICE(X) 



I 



-865 



CMM ISSUES COMMAND OVER LOCAL 

BUS (e.g.. IEEE 1394) TO DEVICE(X) 
USING THE PHYSICAL ID OF DEVICE(X) 



I 



■870 



(return) 



FI0.15A 
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EP 0 929 170 A2 



APPUCATION ISSUES COMMAND TO 1—910 
DETERMINE COMMUNICATION SPEED 
BETWEEN DEVICE(X) AND DEVICE(Y) AND . 
INCLUDES DEVICE(X)'sAND DEVICE{Y)'s GUIDs 



I 



CMM RECEIVES COMMAND AND 
DETERMINES PHYSICAL IDs FOR DEVICE(X) 
AND DEVICE(Y) USING THE GUID LIST 



I 



-915 



CMM USES DETERMINED PHYSICAL IDs 
TO ACCESS SPEED MAP TO DETERMINE 
SPEED BETWEEN DEVICE(X) AND DEVICE(Y) 



T 



-920 



CMM FORWARDS DETERMINED k"925 
SPEED TO APPLICATION REQUESTER 



r 



(return^ 



FIO«lSB 
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EP 0 929 170 A2 



r 

APPLICATION ISSUES COMMAND TO 
DETERMINE TOPOLOGY DATA FOR DEVICE(Y) 
AND INCLUDES DEVICE(Y)'s QUID 



I 



CMM RECEIVES COMMAND AND DETERMINES 
PHYSICAL ID FOR DEVICE(Y) USING GUID LIST 
AND DEVICE{Y)'sGUID 



I 



CMM USES DETERMINED PHYSICAL ID 
TO ACCESS TOPOLOGY MAP TO 
DETERMINE TOPOLOGY DATA FOR DEVICE(Y) 



CMM FORWARDS DETERMINED TOPOLOGY 
DATA TO APPLICATION REQUESTER 



(return) 



FI0.15C 
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EP 0 929 170 A2 



APPUCATION ISSUES COMMAND TO 
DETERMINE COMMUNICATION SPEED 
BETWEEN DEVICE(X) AND DEVICE{Y) 



I 



-980 



CMM RECEIVES COMMAND AND FORWARDS |-^982 
QUID LIST AND SPEED MAP TO APPLICATION | 



APPLICATION USES QUID LIST AND QUID'S FOR 
DEVICE(X) AND DEVICE{Y) TO DETERMINE PHYSICAL IDs 

and accesses speed map therewith to 
determine speed between device(x) a nd device(y) 

( ireturn) 



45 



EP 0 929 170 A2 



950b 



("enters 



APPLICATION ISSUES COMMAND 
TO DETERMINE TOPOLOGY DATA 
FOR DEVICE(Y) 



T 



■990 



CMM RECEIVES COMMAND, AND FORWARDS 
QUID LIST AND TOPOLOGY W TO APPLICATION 



I 



•992 



APPLICATION USES QUID LIST AND DEVICE(Y)'s QUID 
TO DETERMINE PHYSICAL ID TO ACCESS TOPOLOGY 
MAP TO DETERMINE TOPOLOGY DATA FOR DEVICE(Y) 



■994 



(RETURN) 



FI0.15£ 
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